home *** CD-ROM | disk | FTP | other *** search
/ Internet Tools (InfoMagic) / Internet Tools.iso / dos_win / winsock / hacklist / 94-04.Z / 94-04 / 000016_stcheng@ee.tamu.edu_Wed Apr 20 19:28:52 1994.msg < prev    next >
Internet Message Format  |  1994-04-30  |  1KB
  1. Received: from EE.TAMU.EDU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  2.           id AA21103; Thu, 21 Apr 1994 01:27:20 -0400
  3. Received: by ee.tamu.edu (5.61/1.34)
  4.     id AA09209; Thu, 21 Apr 94 00:28:53 -0500
  5. From: stcheng@ee.tamu.edu (Franklin S. Cheng)
  6. Message-Id: <9404210528.AA09209@ee.tamu.edu>
  7. Subject: Essential Winsock problems
  8. To: winsock-hackers@sunsite.unc.edu (WINSOCK)
  9. Date: Thu, 21 Apr 1994 00:28:52 -0500 (CDT)
  10. X-Mailer: ELM [version 2.4 PL21]
  11. Content-Type: text
  12. Content-Length: 936       
  13.  
  14.  
  15. Dear hackers,
  16.  
  17. I have an essential winsock problem : what will happen when my
  18. program keeps running(never return) while monitoring FD_READ by using
  19. WSAsynchSelect(), can winsock.dll or the real TCP/IP stacks
  20. receive the incoming packets ? My doubt is if the real IP-layer
  21. receives packets by interrupt or from Windows 'pseudo' multitasking ?
  22. If it's the latter, of course , not to mention it.
  23.  
  24. As I know, the DOS TCP/IP stacks receive packets via the 
  25. interrupt vector provided by packet drivers or shims. So that even
  26. the CPU is busy in running user programs, it's still possible to
  27. receive packets via interrupt. What about under Windows ?
  28. Is there any way to wake up the TCP/IP stacks to receive the
  29. incoming packets ? And because the TCP/IP stacks normally have
  30. some amount of buffer, user programs would not lose packets then.
  31. (if the incoming traffic is not too terrible) ,it would be nice
  32. if it's possible.
  33.  
  34. thanks,
  35. Franklin.